<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><head>


<meta http-equiv="content-type" content="text/html; charset=UTF-8"><meta http-equiv="content-type" content="application/xhtml+xml; charset=UTF-8"><style type="text/css">
pre {background: #eee; border: 1px dashed #889; margin-left: 3em; padding: 1ex;}
</style></head><body><div align="center"><h1>Laboratorio 3</h1>
<h2>Redes y Sistemas Distribuidos 2008</h2>
<h3>23 de Abril de 2008</h3></div>





<h4>Objetivos</h4>
<ul>
  <li>Unificar el servidor y el cliente HFTP en un solo programa.</li>
  <li>Trabajar con un sistema distribuido en vez de un sistema cliente/servidor.</li>
  <li>Manejar pedidos y respuestas de forma concurrente.</li>
</ul>

<h4>Motivación/Trasnfondo</h4>

<p>En los laboratorios anteriores se estuve trabajando con la implementacion
de un protocolo clinete / servidor. Esto quiere decir que el servicio 
se provee en un solo punto, que recibe multiples conexiones. El servidor
interactua con todos los clientes, pero estos no interactuan entre si.
 Esta es una
arquitectura de servicio de red frecuentemente usada y simple.</p>

<p>Hay ocasiones en las cuales un servicio se puede implementar de forma
mas distribuida: muchos nodos, donde niguno es diferente a los demas,
sino que cada nodo provee el servicio y usa los servicios de los demas.
En los protocol que implementan estos servicios no hay nodos con roles
distintos; todos son "pares". De esto viene la denominacion normal
de estos protocolos que son llamados "peer to peer" (abreviado usualmente
como P2P).</p>

<p>Los protocolos P2P suelen ser un poco mas complejos de implementar que
los cliente/servidor (porque cada proceso tiene que saber cubrir los roles
de servidor y de cliente simultaneamente). Por otro lado, un servicio provisto
por una malla P2P es mas robusto (si se cae cualquier nodo, muchas veces puede
ser suplantado por los restantes), y permite balancear mejor los recursos
de todos los nodos.</p>

<h4>Extensión al Protocolo</h4>

<p>La especificación del protocolo se mantiene <b>exactamente</b> igual que en
   los 2 labs anteriores, con los siguientes comando agregado:</p>

<pre>hello port-number</pre>

<p>Este nuevo mensaje <b>debe</b> ser enviado al inicio de una
conversación, desde una instancia en modo cliente hacia una en modo
servidor. Si en una conexion recibida se recibe otra cosa como primer
mensaje <b>debe</b> responderse el codigo 102 (handshake incorrecto) e
interrumpirse la conexion. Tambien debe usarse el codigo 102 al recibir
un mensaje de <code>hello</code> que no venga como primer mensaje de una
conexion. A un mensaje de saludo correcto se le responde con estado 0, y
sin informacion adicional.</p>

<p><i>port-number</i> es el número de puerto en donde la instancia que
inicia la comunicación está escuchando pedidos.</p>

<pre>new_file</pre>

<p>Este mensaje debe enviarse por el proceso a cada uno de los servidores
con los que esta conectado luego de descargar archivos nuevos. Debe ser
respondido siempre con codigo 0.</p>

<h4>Tarea</h4>

<p>Utilizando el servidor ya codificado en los labs anteriores, deberán ampliar el mismo
para que también funcione como cliente HFTP.
</p>

<p>El programa resultante debe:

</p><ul>

  <li>Manejar cualquier cantidad de conexiones simultáneas, tanto
  entrantes como salientes.</li>

  <li>Respetar al pie de la letra el protocolo enunciado en el Lab1, con
  el agregado de los nuevos mensajes <tt>hello</tt> y 
  <code>new_file</code>.</li>

  <li>Soportar pedidos/respuestas truncados, con '\0' en el      
  cuerpo, offset y/o tamaños fuera de rango, etc.</li>

  <li>Aceptar como argumentos de ejecución una lista no acotada de
  strings (puede ser vacía), que indica direcciones de la forma
  <tt>server:port</tt>. Estas direcciones deberán ser usadas para
  entablar conexiones al inicio.</li>

  <li>Bajar todos los archivos que le provean todos los otros
  servidoers. Los servidores se descubren de dos formas: o bien a través
  de las direccions pasadas como parámetros, o bien por conexiones
  entrantes, utlizando los datos del mensaje inicial obligatorio
  <tt>hello</tt>.</li>

  <li>Si el nombre de un archivo provisto por un servidor ya existe en
  el directorio de archivos que se exportan, o esta siendo bajado,
  tal <b>no</b> deberá ser bajado.</li>

</ul>

<p>Es importante tener en cuenta que: dadas dos conexiones cualesquiera,
tal que en ambas hay archivos distintos que el programa ejecutante no
tiene, es requisito bajar <b>simultáneamente</b> de ambas dos conexiones
</p>

<!--
<h4>Consejos utiles:</h4>

<ul>
   <li></li>
</ul>
-->

<!--
<h4>Algunas pruebas a realizar</h4>

 Esto fue lo que dijo Pablo al frente
Ej:

tenemos 3 clientes, A, B, C con archivos a, b, c

cada cliente-server se lanza con un listado de servers

A se lanza sin par�metros

B se lanza con 1 par�metro (A)

-> cuando A recibe la conexion de B, se conecta a B y se baja sus archivos

A queda con a y b, B con b y a

Esta es la primer complicaci�n!!! bidireccionalidad

C se lanza con 2 (A, B), con lo cual C se conecta a A y a B

-> A recibe la conexion de C, por lo tanto A se conecta a C
-> B recibe la conexion de C, por lo tanto B se conecta a C

C debe bajar todos los archivos de A y de B, y de cualquier otro servidor que pueda.

<ul>
  <li>XXX: ponemos algo acá?</li>
</ul>
-->
<h4>Requisitos del código a entregar</h4>
<ul>
<li>La fecha de entrega es el jueves 8 de Mayo, hasta las 23:59.</li>
<li>Se deberá enviar un archivo cuyo nombre sea <b>LabYGXX.tar.gz</b>
    donde <b>XX</b> es el número de grupo e <b>Y</b> es el número de laboratorio.
	Por ejemplo, si el número de grupo es 1, el archivo que deberán enviar será: <b>Lab3G01.tar.gz</b></li>
<li>Junto con el código, se deberá entregar un informe en el cual se explique detalladamente
    la estructuración e integración del cliente, las decisiones de diseño tomadas,
	dificultades con las que se encontraron, y cómo las resolvieron. 
El formato de dicho informe queda a elección de ustedes, siempre y cuando sea un formato libre.</li>
<li>Se deberá mantener un estilo de codificación uniforme.</li>
<li>También se exigirán las metodologías de programación defensiva y de buen manejo de memoria,
    aprendidas en materias anteriores.</li>
<li>El trabajo es grupal. Todos los integrantes del grupo deberán poder explicar el código presentado.</li>
<li>No está permitido compartir código entre grupos.</li>
</ul>


</body></html>